|
|
|
|
|
|
|
Discoveries should diminish in time and will often affect the architecture of your system at some point. Assessing the state of your Visual Basic project with regard to discovery resolution is an important activity that should be periodically performed. Factors to take into consideration for state assessment include |
|
|
|
|
|
|
|
|
The number of interface and implementation classes |
|
|
|
|
|
|
|
|
The number of classes that implement the interface classes |
|
|
|
|
|
|
|
|
The number of public methods per class |
|
|
|
|
|
|
|
|
The number of interface and implementation classes indicates how well focused your project is. You typically have more implementation classes than interface classes, though a class can implement more than one interface. It is perhaps better to plan your applications to have subsystems and components that implement more than one interface. Nevertheless, given a reasonably complex application, if your project tends to have no interface classes, that's a red flag indicating the application architecture is lacking. |
|
|
|
|
|
|
|
|
The number of public methods per class indicates how well the architecture of the application is evolving. It is certainly okay to have classes that have nothing but public methods. However, most of your classes should typically have private methods. More complex classes should have a handful of public methods but possibly 15 or 20 private methods and more. If your complex classes require more than 20 public and private methods, though, you should consider dividing the classes into smaller classes. In so doing, make sure there's minimal coupling between the classes. |
|
|
|
|
|
|
|
|
Coupling between objects helps ensure proper encapsulation. Objects with well-defined classes will not duplicate the behavior of dissimilar objects at runtime. Ways of determining well-defined classes include the following: |
|
|
|
|
|
|
|
|
Determining, in your own opinion, whether the classes have evolved properly. Of course, with this approach, you might be biased in favor of your creation. Therefore, in cases when your opinion is the only one available, it's good to spend some time away from a subsystem or component and to work on another. Some time later (perhaps a week), revisit the subsystem. If you can still follow the behavior and logic of the classes in it, they're probably okay. |
|
|
|
|
|
|
|
|
Conducting peer reviews. Having peers, especially expert object-oriented developers, review your class structures is very effective. |
|
|
|
|
|
|
|
|
Conducting user reviews. If your users can identify your domain classes, including properties and methods, your classes are typically in good shape. For commercial application developers, for proprietary reasons, you probably can't show your users |
|
|
|
|
|